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154) Abstract Title: Rulm bssod tvcheti ng for Mff-ochoduling of oppointmsnts 



15?) A sy^em and method ar^ provided for self-ochwdulinfl appoiotments via an electronic network. Tine user 
aefida a sch^uHn^ requ^t tn a server ^rwi ttie duthof isation of the UJter an<if<ir the le^^uesst \s dfttetmirted. 
Upyon the nMeipi of an jjuttiori?e<l request a database is ftcceaaed to idemfty s pre -ai^Thorised scheduling 
ticket for the u.TCr. the pre-^uthorised scheduling rtctet ircluding 3ppointfr\ent itched iilFrtg information. An 
apppintvrrent proposal in accordance with Tlie appointment 5Checl<|ling LrvformariDn is provided to the 
user. Once a achedule ha» been accepted the informarion is included in the database. A f»et of rules can be 
applied to die appointment request to determfne if the requested appoimmant f» allowed. The set o-f rules 
can be hFerarchrcal in nature. 
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RULES BASED TICKETING FOR SELF-SCHEDULING OF 

APPOINTMENTS 

Field of the Invention 

Tlie present invention relates generally to health records management, and more particularly, to a 
system for providing a patient with access to the patient's health record 

Background of the Invention 

A variety of Internet-based systems for providing access to a patlenfs health record and redated 
healthcare information have been proposed. Such Intemet-based personal or patient medical 
records either provide patients access only to information that they enter and maintain 
themselves, or provide them with ddayed and limited access to information contained in a 
separate healthcare Infonnation system from which patient health infonnation must be abstracted 
and uploaded to a web server in regularly scheduled batch processes. A patient is unsure if the 
information they are viewing is the most up to date and complete. Apart from the ability to view 
selected portions of information or patient self-generated information, the proposed systems have 
not provided an effective forum to allow the patient to communicate with their health care 
providers. None of the proposed systems feature secured, real- time access to an integrated 
patient health record. 

Many attempts have previously been made to streamline the process of scheduling appointments 
for patients In the healthcare Ir dustry. From a healthcare organization's point of view, the most 
efficient method is to (d patients schedule appointments themselves. However, until the advent of 
the laternet, this solution was not feasible. Now. the Intemet has provided patients with direct 
access to an organization through the web. thereby opening up the possibility of self-scheduling. 
Nevertheless, selfscheduling over the Intemet presents umique and interesting problems. For 
example, there are always security issues when dealing with medical information on the Intemet. 
Also, if the system is not implemented property, patients could abuse the system. Furthermore, 
Healthcare providers, such as doctors, nurses, and 

I 

surgeons oRen have concerns that they are losing control of their daily schedules if they allow 
patients to schedule their own appointments. 

The existing scheduling solutions are based on messaging or very restricted access. These 
solutions allow patients to enter some limited infonnation concerning an appointment. Some 
examples are: (1 ) which provider the patient wants to see, (2) the day and time the patient wants 
to be seen. (3) some of the patient's insurance information, and (4) a few other types of 
information relevant to scheduling. 

After requests were submitted in the previous systems, workers at the clinics were then required 
to review each of the requests and contact every patient individually to inform him or her whether 
or not the request was granted. While this process is somewhat convenient for the patients, it 
does not automatically schedule appointments or immediately enter the data into the 
organization's system. Rather, it relies on human intervention to evaluate p the requests and 
contact the patients when the decision to schedule the appointment has been made. : Thus, there 
is a need for a patient health record access system that, j provides real-time communication 
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between the patient and an integrated! Patient Health Record (PHR) and an Enterprise Health 
Infonmation System (EHIS). Such a system would provide patients with the most up-to-date 
information. Moreover, patients coutd avail themselves of electronic health related services in 
real-time. Furthemriore. a real-time, integrated PHR/EHIS system could provide efficiency, 
workflow flexibility and connectivity between patients and their health care providers and affiliated 
staff that are not available using previously disclosed systems. 

There is also demonstrated a need for healthcare organizations to allow the full scheduling of 
appointments over the Internet In an automated process that gives patients immediate results and 
eliminates the need for employees of the facility to review each request for an appointment. None 
of the previous systems satisfied this need. - 3 

Brief Description of the Drawings 

FIG. I is a system block diagram of a patient health record access system in accordance vwth a 
preferred embodiment of the invention. 

FIG. 2 is a flowchart illustrating operation of the system illustrated in FIG. 1. 

FIG.Sis a flowchart illustrating operation of a content relevancy engine portion of the system 
illustrated in FfG.l, 

FIG-4is a flowchart illustrating operation of the system illustrated tn FIG. I for viewing of 
information by the patient. 

FIG. 5 is a flowchart illustrating operation of the system illustrated in FIG. I for processing 
messages. 

FIG.6 is a flowchart illustrating operation of the system illustrated in FIG. I for accepting and 
recording information from a patient. 

FIG.Zis a flowchart Illustrating operation of the system illustrated in FIG.I for scheduling 
appointments in accordance with a preferred embodiment ofthe invention. 

FIG. 8 is a flowchart illustrating operation of the system illustrated in FM. I for scheduling 
appointnr>ents in accordance with another preferred embodiment ofthe invention. 

FIG.Qis a flowchart illustrating operation ofthe system Illustrated in FIG.I for providing dass 
enrollment. 

FIG.IOis a flowchart illustrating operation of the system illustrated in FIG. 1 for paying bills. 

FIG. 1 1 is a flow chart representation of the path that the system would take when a patient 
attempted to schedule an appointment directly from the system. 

FIG. 12 is a flowchart that illustrates the process by which a user logged in to his Patient Health 
Portal (PHP) Web Page can schedule an appointment that has been pre-qualified. 

FIG. 13 is a flowchart illustrating the components and connections from He enterprise healthcare 
information management system through the Intemet and on to the patient via a web page portal. 

Detailed Description of the Preferred Embodiments 

An integrated system provides patients with secure, real-time access to their Personal Health 
Record and an Enterprise Health Infonnation System (PHR and EHIS, respectively). Access may 
be provided by way of the Internet and via a Personal Health Portal (PHP) web page. From the 
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secure PHP web page, patients can view infonnation created and nnaintained by their health care 
providers and their affiliated staff. The patients can also request services and information from 
their heaith care providers and affiliated staff, directly access EHIS-related services, such as 
scheduling an appointment, paying a bill, enrolling in a class, completing insurance and other 
forms, and viewing infomiation and Internet services that are relevant to their particular health 
status. 

In a preferred embodiment of the invention a patient health record data server, including a 
machine-readable media having a data structure containing patient-created data, Is coupled by a 
communication network with a patient interface. The communication network may be the Internet 
and the patient interface may be a suitable Internet access device including a browser for 
supporting a personalized web page. A secure interface securely couples, in real-time, the patient 
health record server to an enterprise health record system for providing access by the patient to 
patient-related data retained within the enterprise health record system. Thus, the patient, via the 
patient interface, may access the patient health record server for manipulating the patient created 
data and for accessing the patient-related data from the enterprise health record system. 

According to a preferred embodiment of the invention a system that enables a patient to use a 
pre-authorized or a user initiated scheduling process that utilizes hierarchically-layered rules. The 
system further provides dynamic feedback to self-schedule appointments with a user's preferred 
clinics and providers in a confidential and secure manner. 

The rules^ based ticketing system for self-scheduling provides healthcare clinics and providers the 
ability to manage and control patient appointment utilization. 

For several reasons, it is very desirable Mom a healthcare provider's perspective to - 5 allow 
patients to schedule their own appointments. It is also desirable from a patient's perspective to be 
able to independently schedule their own appointments at their convenience through the Intemet. 
A system according to the preferred embodiments of the invention satisfies the desires of t>oth 
parties. 

While described in terms of several preferred embodiments, it will be appreciated that the 
Invention is not limited in scope to the embodiments herein described. Many modifications, 
alterations and additions may be made without departing from the fair scope of the invention. 

Refemug to FIG. I ofthe drawings, a patient access system 10 includes a Patient Health Record 
(PHR) data server 12 and an EHIS data server 14. The PHR data server 12 may be any suitable 
platform including processing, memory and data storage capability to perfonn the functions herein 
described. The PHR data server 12 stores data entered by the patient within a data structure 
configured within the storage portion 26 ofthe PHR data server 12. A secure interface or EHIS 
queue 1 6 securely couples the PHR server 12 and the EHIS data server 14 for communication of 
data and information from the PHR data server 12 to the EHIS data server 14. The EHIS Queue 
16 provides a real-time secure communication link for information moving from the PHR data 
server 12 to the EHIS data server 14. This queue is used to transfer infonnation for secure 
messaging and selfservice options, in response to information received from the PHP web page, 
the PHR data server 12 forwards information to the EHIS queue 16. Infonnation in the EHIS 
queue 16 is then processed appropriately by the EHIS data server 14. 

While the specific configuration of the EHIS data server 14 is not particular to the structure and 
function of the present invention, preferably, the EHIS data servo 2S 14 is a single data repository 
structured to support both the separation and the sharing of data As such, the EHIS data server 
14 may receive information Bom existing outpatient and inpatient data management systems via 
interfaces or from various integrated applications. The EHIS data server 14 may be configured to 
organize information into a consistent whole to provide a longitudinal patient record. For example, 
the EHIS data server 14 may be linked to manage all aspects of a patient's hospital health status 
and care and to support effective management of patient lists, results inquiry management. 
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complete clinical documentation, physician order entry with decision support, nursing workflow 
and documentation, and discharge planning. 

The EHIS data server 14 may further be configured to support the inclusion of problem lists, order 
communications, results reporting, pharmacy management, quick docum^tation, clinical 
messaging and communication. Additionally, the EHIS data server 14 may be configured to 
manage referral information, up-to-date progress notes, lab results, discharge instructions, 
portions of a patient's record, and emergency summary cards. A suitable data management 
product that may be adapted as the EHIS data sewer 14 is the Epicenters Enterprise Data 
Repository and related suite of products available from Epic System Corporation of Madison, 
Wisconsin. 

The PHR data server 12 includes a patient services application layer 22, a communication layer 
24. a patient data manager 26 and a content relevancy engine 28, all of which are suitably linked 
within an architecture for operation under the direction of the PHR data server 12. The patient 
data manager 26 includes suitable storage capability, such as magnetic, optical, or other storage 
technology, for storir>g patient-created data. The patient services application layer 22 and the 
coninunication layer 24 include routines for managing access and use ofthe patient-created data, 
as well as to provide patient services. The PHR data server 12 is further linked, by way of the 
content relevancy engine 28 to a source of generic data 30 and a source of news, educational 
and similar materials 32 via a secure connection 34, such as a Internet protocol secure (iPsec) 
connection or by a file transfer protocol (ftp) connection. 

A communication network 36 couples the PHR data server 12 to a patient interface 38. The 
communication network 36 may include the Internet 40 or other suitable data network, and the 
PHR data server 12 is linked to the Intemet 40 by a web server 42 in a highly secure dual firewall 
configuration. In this arrangement, a primary fire wall 44 protects the web server 42 and a 
secondary fire wall 46 protects the PHR data server 12 and the EHIS data server 14 with a 
communication link 48 coupling the communication network 36 to the PHR data server 12. 

In 3 preferred embodiment ofthe invention, a shadow server 50 is prwided and maintains a copy 
of at least the patient-related data retained within the EHIS data server 1 4. A communication fink 
52 pennits the copying of the patient-related data from the EHIS data server 14 to the shadow 
server 50. and a view access only communicatk>n link 56 couples the shadow server 50 to the 
communication network 36, and hence to the patient interface 38.. This an-angement 
advantageously allows the EHIS data server 14 to be highly available for EHIS systems 
operation. Alternatively, the communication network 36 may be directly linked to the EHIS data 
server 14. 

Patients access the system 10 by logging into the web server 42 via the patient interface 38. The 
patient interface 38 Is preferably configured as a web page displayed within a web browser 
running on a suitable platform, and is further preferably configured as a personalized Personal 
Health Portal (PHP) web page providing the patient with patient-specffic information and links to 
the features and services offered by the invention. The web server 42 may be any suitable web 
server platform containing routines for displaying the PHP web page and for managing online 
communication between a user logged in via an associated PHP web page and the PHR data 
server 12 and the EHIS data server 14. 

A user logging into the system via the PHP web page may or may not be an existing patient of 
the healthcare enterprise. For existing patient users, the PHR data server 12 may already contain 
a record for the patient and, as will be described, the user is provided access to the information 
contained in that record. Some existing patents and new patients may not have a record within 
the PHR data server 12. 

These patients will have at least two options for gaining access to the functionality of the system 
10. First, the patient may fully register by providing appropriate identifying. The PHR data server 
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12 creates a patient record for the user. 

A patient may gain access without fully identifying himself or herself. The patient may enter 
patient data using a user name and identifying information that is anonymous in nature. Access 
for this "anonymous user" may be limited to predefined functionality. For example, the 
anonymous user may be p.Jtted only to view information related to services provide by the 
healthcare enterprise, may be able to create a record or patient created information within the 
PHR data server 12, may be able to ask questions of the healthcare enterprise and receive 
responses, and the like. 

The anonymous user, however, would not be permitted to make appointments or request specific 
services of the healthcare enterprise. Additionally, should the anonymous user become a patient 
ofthe healthcare enterprise, the PHR data server 12 may use the anonymous user record to 
create a patient record within the PHR data server 12 without requiring the patient to reenter 
information. 

Operation and use ofthe system is described in more detail with reference to FIGS. 2-10. The 
flowcharts depicted in FIGS. 2-10 are linlced and illustrate the operation of the system 10 in 
accordance with a preferred embodiment ofthe invention. The alpha designations indicate the 
interconnections between the venous flowcharts depicted in the figures. Tuming to FIG. 2 
depicted is a method 200 of providing access by a patient to the PI data server 12 and the EHIS 
data server 14. 

The method 200 begins at step 202 v\^ere the patient accesses a public web page, such as an 
Internet service provider (1SP) home page, with a PHP web page option and selects the PHP 
web page optk)n. step 204. At step 206, the user attempts to log into the PHP web page, which is 
provided by the web server 42, using a suitable authentication technology. The web server 42 
executes the authentication routine at step 208, and a user authorization determination is made 
at step 210. If the user is not authorized, the user is retumed to the public web page. If the user is 
authorized, the content relevancy engine 28 functions, step 212, as will be described in 
connection with FIG. 3, and at step 214, the web server42 generates and displays the usa's PHP 
web page on the patient interface 38. 

From the PHP web page, the user is provided a selection of links providing access to patient- 
relevant content, infonnation from the patient's enterprise health record, and services associated 
with the enterprise health information system. If the user does not dick on a link within a timeout 
period causes the web server 42. at step 216, to log the user out and to return the user to the 
public page. 

At step 218 the user clicks a content link. Depending on the type of content selected by the user, 
step 220. if the item is stored directly in a content database or on the web server 42. at step 224 
the content is displayed on the PHP web page. 

Otherwise, for items stored as URLs, at step 226 the data retrieval and display option associated 
with the linic opens a separate browser page to display the content. 

a preferred embodiment ofthe invention, the user may also select: a view option; a secure 
messaging option, an edit or add notes option; an online form; schedule a prequalified 
appointment option; schedule an appointment option; enroll in a class option; pay a bill option or 
log out, respectively, links associated with blocks 228-244. 

Refem'ng now to FIG. 3, the content relevancy er>gine 28 operates in accordance with a method 
300 depicted therein. At step 302. the web server 42 requests patient-related information from the 
Shadow Server 14 and caches it on the PHR data server 12. This data includes the user's sex, 
age, zip code, medical - 9- problems and diagnoses (using ICD9 codes), procedures (using OPT 
codes) and medications (using GPI & NDC) as indicated at block 306. At step 304, another 
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routine on the PHR data server 12 uses page layout specifications associated with the user's 
PHP web page, which may be specified by the system provider or may be user configurable, to 
determine what types of content to display, and how many items to display of each type. At step 
308. for each type of content specified by the page layout, a routine within the content relevancy 
engine 28 compares the patient-related data to criteria In the content database. The content 
database is maintained on the PMR data server 12 and stores available content for display on the 
PHP web page with each record being categorized by display tyi^e. relevance factors, and 
effective dates as indicated at block 310. The content relevancy engine 28 at step 312 then 
determines if a content Item is relevant based upon the cached patient-related information. At 
step 314. the content relevancy engine 28 then produces a ranked list of relevant content items, 
based on a number of matches between the content cnteria A15 and the patient-related 
information. Then, at step 316, the web server 42 builds the PHP web page according to the page 
layout (step 308), using the highest-ranking content items for each type of content. 

When the user selects a link associated with a view option, secure messaging option, or self- 
service option, the PHR data server 12 initiates a routine associated with the link. Link 228 in FIG. 
2 initiates a view content routine 400 illustrated in FIG. 4. The system 10 advantageously pennits 
viewing of a wide variety of information types including patient-created infonnation stored within 
the PHR data serve 12 and patient-related information stored within the EHIS data server 14. The 
patient-created data may be notes and comments relating to the user's health or requests for 
Information. The patient-related information may be portions of the user's medical record and 
other infonnation created by the health care professionals and staff. In the preferred embodiment 
illustrated in FIG. 4, the user may select to view a health summary, a medication list, lab results, 
health reminders, recent visit information, medical history, upcoming appointments, messages. 
Immunization information, allergies information, current health issues, financial and insurance 
Information, and records access by selecting an appropriate link associated with the requested 
infonnation represented by blocks 402- 424, respectively. Upon the user selecting the link, at step 
426 the web server 42 receives the data request, and at step - !o- 428 initiates a routine to 
retrieve the requested information, either from the PHR data server 12 or the shadow servo 50 (or 
EHIS data server 14 if so configured). At step 430, the web server 42 updates the PHP web page 
with the new information. The web server 42 may retrieve the patient-related infonmation from the 
shadow server 50 in XiVlL format as shown in block 432. Similariy, the web server 42 may retrieve 
the patient-created informatton fiom the PHR data server 1 2 in XML format, the patient created 
inform atk)n includir^ userentered rK)tes or messages. 

The system 10 provides ability for the user to send and receive secure messages to the user's 
health care providers and administrators. Selecting the link I 0 230 in FIG. 2 initiates a secure 
messaging routine 500 illustrated in FIG. 5. The message types include a request for medical 
advice; a request for prescription renewal; a request for a referral; a customer service request; a 
request for a pre qualified appointment and a request for an appointment, and the user sdects the 
message type by selecting an appropriate link associated with the message type represented by 
blocks 502-512, respectively. Responsive to the user selecting one of the links 502-512, at step 
514, the web server 42 creates a secure messaging form on the PHP web page for the selected 
message type. At step 516, the user enters the appropriate data and information into the 
message fomn. The user may cancel the message, step 518, and be returned to the previous 
PHP web page, or the user dicks send, step 522. The web server 42 forwards the Information to 
the PHR server 12. step 524, and the PHR server 12 places the user's message in a queue for 
transmission to the EHIS data server 14. At step 528, the EHIS data server 14 receives the 
incoming message from the queue, and translates and routes the message to the appropriate 
destination, and at step 530, the web server 42 updates the PHP web page to reflect that the 
user's message has t>een sent. 

Selecting the link associated with block 232 (FIG. 2} allows the user to add notes to the patient- 
created information, and selecting the link associated with the block 234 allows the user to 
complete fonns. Selecting either link 232 or 234 initiates a process 600 Illustrated in FIG. 6. 
Additionally, the user may add infonnation flags to the patientcreated information and/or other 
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information contained with the PHR server 12. The information flag (dentifies the flagged 
infonnatjon and may provide read only access of He information to one or more of the user's 
health care professionals and stay Coupled with the infcnnation flag, the PHR server 12 is - 1 1 
adapted to generate an alert that is communicated to the EHIS data server 14 indicating the 
receipt of the flag. Appropriate messaging may also be generated and communicated to the one 
or more of the user's health care professionals and staff. 

If the user has selected the link associated wHh block 232, the web server 42 creates an add/edit 
notes form and displays the form on the PHP web page. At step 604, the user enters or edits the 
note text in an editing window. If the user selects cancel, step 606, the notes/edits are discarded 
and the web server 42 returns to the previously displayed PHP web page. If the user clicks to 
save changes, step 610. the web server 42 forwards the edited text to the PHR data server 12, 
step 612, and the PHR data server 12 updates the patients notes portion of the patient-created 
date stored within the PA data server 12, step 614. The user notes may be unstructured 
information, such as unstructured text notes, or the notes may be structured information. As an 
example, to input structured infonmation the user may be presented with a Bonn seeking 
partk:ular information, such as medications they are currently taking or procedures they have had 
or will have. The fields within the fonn may be linked to other data entries in the enterprise health 
record system, such as reference materials for the entered medication or procedure. Moreover, 
the information need not be clinical in nature, as described in foregoing examples, but may be 
administrative in nature, such as benefits information. 

A similar process occurs if the user has selected the link associated with block 234. The web 
server 42 creates an online form, such as an insurance fomn or medical history form, and displays 
the forth on the PHP web page, step 616. At step 618. the user enters information into the form in 
an editing window. If the user selects cancel, step 620, the infonnation and form are discarded 
and the web server 42 returns to the previously displayed PHP web page, step 608. If the user 
clicks to save changes, step 622. the web server 42 forwards the edited form to the PA data 
server 12. step 624, and the PHR data server 12 forwards the information from the edited Bonn to 
the EHIS server 50, step 626, where it is processed appropriately. The web server 42 then 
returns the user to the previous PHP web page, step 6aS. 

By selecting the link associated with the block 236 (FIG. 2) the user may schedule a prequalified 
appointment in accordance with a process 700 illustrated In FIG. 7. Upon selecting the link, the 
web server 42 queries the shadow server 50 for a list of available appointments for the current 
user, step 702. Whether prequalified - 12- appointments are available will depend on the 
existence of a scheduling ticket illustrated at 704. The scheduling ticket is provided by the 
shadow server 50 responsive to input received from a care provkier and specifies whk:h providers 
are available, what procedures are required and dates and tizues that the appointment may be 
scheduled. If there are appointments available, step 706. the web server 42 updates the PHP 
web page with a listing of the appointments, step 708, At step 710, the user selects an 
appointment to schedule and, if necessary, provides additional information necessary to nannow 
the search for dates, times, etc. The usa may also cancel the process at step 712, and web 
server 42 returns the user to the PHP web page. 

Otherwise, at step 714, the PHR data server 12 requests available appointments from a 
scheduling engine portion (not depicted) of the shadow server 50. If there are no appointments 
that meet the user specified criteria, step 716, the web server 42 updates the PHP web page, and 
the user is requested to enter revised information. Othenwise. at step 718 the web server 42 
displays the list of available appointment times on the I 5 PHP web page. At step 720, the user 
sdects an appointment, and the web server 42 forwards the appointment selection to PHR data 
server 12, which places the request in the EHIS queue 16 for processing by the EHIS data smer 
14. When the appointment is booked, the updated appointment information flows via the shadow 
server 54 from the EHIS data server 14 tothe web sen/er. which updates the PHP web page with 
the selected appointment summary information, step 728. The web server 42 also updates the 
scheduling ticket to reflect that a prequalified appointment has been scheduled. The user may 



PACE 10/29 * RCVD AT 6/28/2005 0:61:39 AM tEastem OayUghtTane] ' SVR:USPTO-EFXRF-iyi * DNIS: 8729300 * CStD:7249345401 * DURATION (ntn^ss): 12-20 



Jun 28 05 09:03a 



Catherine Belleci 



72493454G1 



p. 1 1 



Otherwise cancel the scheduled appointment at step 722 and be returned to the PHP web page. 

A second appointment option is initiated by selecting the link associated wrth block 238 (FIG. 2), 
which starts a process 800 illustrated in FIG. 8. After the user selects the link 238» the web server 
42 queries the shadow server 50 for a list of available providers for the user, step 802. At step 
804, the web server 42 updates the PHP web page with a list of the providers. At step 806, the 
user selects a provider and provides additional information, such as dates and times for the 
appointment. 

The user may also cancel, step 808, and the web server 42 retums the user to the PHP web 
page. Otherwise, at step 810 the PHR data server 12 requests available appointments 
infonnation from the scheduling engine portion of the shadow server 50. If there are no 
appointments within the date and time range provided by the user, - 13 step 812, the web server 
42 updates the PHP web page for the user to provide additional information. Otherwise, the web 
server 42 updates the PHP web page with a list oflhe available appointments, step 814. At step 
816. the user selects an appointment or cancels the process, step 818. If an appointment is 
requested, the web server 42 forwards the appointment infonnation to the PHR data server 12, 
which places the information in the EIIIS queue 16 for processing by the EHIS data server 14. 
When the appointment is booked, the updated appointment information flows via the shadow 
server 54 from the EHIS data server 14 to the web server, which updates the PHP web page with 
the selected appointment summary information, step 822. 

By the user selecting the link associated with block 240 (FIG. 2) a process 900 illustrated in FIG. 
9 is started that allows the user to enroll in a class. After the user sdects the link 240. the web 
server 42 queries the shadow server 50 for a list of available classes for the user, step 902. At 
step 904. the web server 42 updates the PHP web page with a list of the classes. At step 906, the 
user selects a class or cancels the process, step 908. If the user cancels the process, the web 
server 42 retums the user to the PHP web page. Otherwise, at step 910 the PHR data server 12 
requests available class times from the scheduling engine portion of the shadow server 50, At 
step 912, the web server 42 displays the list of available class times, and at step 914 the user 
selects a class time or cancels. If an appointment is requested, the web serve 42 forwards the 
appointment information to the PHR data server 12, which places the information in the EHIS 
queue 16 for processing by the EHIS data server 14. When the appointment is booked, the 
updated appointment information flows via the shadow server 54 from the EHIS data server 14 to 
the web server, which updates the PHP web page with the selected appointment summary 
infonnation, step 920. If the process is cancelled, the web server 42 retums the user to the PHP 
web page. 

By selecting the link associated with the block 242 (FIG. 2> the user may initiate a process 1000 
illustrated in FIG. 10 for paying a bill. The process 1000 begins at step 1002 with the web server 
42 making a query of the shadow server 50 for accounts for the user. The web server 42 at step 
1004 updates the PHP web page with an accounts listing. The user may select an account at 
step 1006. or may cancel, step 1 008. If the user cancels, the web server 42 retums the user to 
the PHP web page, step 1010. If the user does select an account, at step 1012 a routine on the 
PHR - 14 - data server 12 requests infonnation from an accounts receivable engine portion (not 
depicted) of the shadow server 50. The account is checked to detemiine If there is an outstanding 
balance, step 1014. The user may then return to the PHP web page providing the account listing. 
The user may elect to pay all or a portion of any balance due or may elect to pay ahead to 
develop an account credit toward an upcoming procedure. To permit the user to make a payment, 
the web server 42 displays a pay online option for the account, step 1016. The usa may click the 
pay online option, step 1018, and the web server updates the PHP web page with an online 
payment Bonn, step 1020. The usa completes the online payment form, step 1022, or the user 
may cancel the process, step 1024 and be returned to the PHP web page. At step 1026, the web 
server 42 forward the information from the completed payment form to the PHR data server 12, 
whk:h places the information in the EHIS queue 16 for processing by the EHIS data server 14. 
When the payment is processed by the EHIS data server, the infonnation flows via the shadow 
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server to the web server 42, which updates the PHP web page 38 with a message indicating that 
the payment has been submitted, step 1028. 

A rules-based scheduling system according to a preferred embodiment of the invention allows a 
facility to control appointments scheduled through the InteTnet. 

with Scheduling tickets that incorporate a variety of rules and triggers. These rules can be defined 
as many things. Some examples that may be rnduded are: (1) The type of patient. The system 
checks if the patient has any special conditions, such as being diabetic or undergoing cancer 
therapy, that would allow or disallow a patient to seff-schedule. A clinic may not want certain 
patient types scheduling their own appointments because some patients need special 
consideration. 

(2) A patlenfs Insurance. The system checks to ensure that patients have insurance or other 
methods to cova their medical expenses. 

(3) Referral information. The system checks to ensure that patients do not have any outstanding 
referrals for that type of visit so that appointments are not duplicated. 

(4) Previous visits of a certain type. The system checks if patients are due for or require a follow 
up appointment. For example, a minor operation may warrant a retum visit to remove the sutures. 



(6) Provider preferences. The system takes into account when providers can or want to see 
certain types of patients. For example, if a provider does not want to schedule physicals In the 
morning, the system could reject any ticket submission from patients to have physicals scheduled 
in the morning for this particular provider. 

(6) Patient preferences. The system takes into account when patients want to be seen by their 
providers. 

(7) Past patient history. The system checks If factors exist that may change whether or not a 
patient can self-schedule. For instance, a system could deny a patient the right to self-schedule 
because he has a history of more than 20% no-shows or cancellations. 

(8) Copay requirements. The system checks if a copay by the patient is required for the 
appointment. Accordingly, the system requires that a patient must pay the copay when he or she 
schedules the appointment. 

These rules could further be set up as a layered hierarchy. They could be - specified at various 
levels which Include, but are not limited to: (1) System level or facility level. This is the least 
specific level. The settings at this level pertain to an entire healthcare facility. 

(2) Department level. This level is more specific than the system level. The settings at this level 
pertain to all providers who work in a specific department of a facility. 

(3) Provider level. This level is very specific. The settings at this level pertain to only a specific 
provider. 

(4) Rule level. The specificity of this level could vary, depending on how a facility has set up the 
system. For example, one facility could set up the rules level settings as overriding settings at the 
provider level, while another facility could set up settings at the provider level as oveniding the 
settings at the rules level. The settings at this level pertain to only a specific mle. 

Rules set at more specific levels could override rules set at lessspecific levels. 
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For example, if an entire clinic's system Is configured to allow diabetic patients to self-schedule 
using pre-authorized scheduling tickets, but a diabetic pab'ent attempts to use a scheduling ticket 
to schedule an appointment in a department that does not allow diabetic patients to selfschedule, 
the patient would not be able to self-schedule in that department because the department level Is 
more specific than the system 16 level, so it takes precedence. However, diabetic patients in 
departments that allow diabetic patients to use self-scheduling or in departments with no spedfic 
rules for diabetic patients could still schedule an appointment with a ticket. 

DifTerent rules could also be set up to override other rules. For example, provider preference rules 
could be set up to ovem'de patient preference mles when a patient is using a scheduling ticket to 
make an appointment. Also, the past patient history rules could be defined to override ail other 
njles. because if a patient abuses self-scheduling, a facility would most likely not want that patient 
to be scheduling appointments, re^rdless of what the other oiles dfctate. 

Furthermore, these rules can be dynamic in their ability to change over time. 

For example, the system could revoke a patient's ability to self-schedule if the patient abuses the 
system. Therefore, if a patient self-scheduled three appointments and did not show up for them, 
the system could automatically change the patient's status from "able to setf schedule" to "unable 
to self schedule." While the invention is further described in terms of several preferred 
embodiments, it will be appreciated that the invention is not limited in scope to the embodiments 
herein described. Many modifkjations, alterations and additions may be made without departing 
from the fair scope of the invention. 

Referring to FIG. 1 1 of the drawings, a flow chart representation is shown of the path that the 
system would take when a patient attempted to schedule an appointment directly from the 
system. Through the system, a patient with access to self-scheduling can, either with a pre- 
authorized scheduling ticket or through a user initiated scheduling process, request an 
appointment with his or ha clinic or provider. 

The self schedule request would then have to pass a series of checks, or rules, before it could be 
fulfilled. First, the system would run 1 104 a rules check to see 1 106 if We patient is authorized to 
self-schedule appointments. If the patient has the appropriate authorization, the system would 
then check 1 110 to see if a pre-authorized scheduling ticket existed for the patient. If one existed, 
the system would offer 11 14 the patient time slots that met the ticket requirements. 

If there were no pre-authorized tkjkets for the patient, he or she would enter an appointment 
search criteria manually 1112. Then the system would verify that the patient was allowed to see 
the search results, whether the search results were obtained using the pre-authorized ticket or 
using search criteria initiated by the patient. The 1-17 patient would then select 1 1 18 an 
appointn^ent to schedule. The system would perfonn 1 120 one last check to make sure the 
patient was allowed to schedule the appointment and that the appointment was still available, and 
then the appointment would be made 1 124. If the specific appointment that the patient was trying 
to book was unavailable, the patient would be prompted 1 1 1 2 to enter scheduling infonnation 
manually, and the process would start over. 

Again, if the scheduling ticket or the responses from the user initiated scheduling process pass all 
of the appropriate security checks, the system then can present the patient with a list of solutions 
that match his or her request. After the patient selects an appointment 1118, the system can 
perfomn 1 120 a final check to ensure that the patient is authorized to use the ticket to schedule 
the appointment and that the time slot is still available. If the request passes this security checlc, 
then the system can notify 1 124 the patient that he or she has successfully scheduled the 
appointment with his or her clinic or provider. If for any reason, a patient is not j - allowed to self- 
schedule, the system could be configured 1 108 to immediately dive the patient the option to 
request an appointment, as opposed to actually scheduling one with a scheduling ticket. 
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This self-scheduling computer application would identify and authenticate the patient and read the 
database of electronic tickets to determine what self-scheduling limits exist for the patient The 
self-scheduling application then allows the patient to select appointments that are within the 
limitation of the ticket. 

Once an appointment is made, it is associated with the ticket. The ticked is then marked as 
Appointment made.n When the appointment is kept, the ticket is marked as Appointment 
completed aid then subsequently destroyed or retained for historical analysis. If the patient or 
provider cancels the appointment, the ticket's status would revert to the Unused status. 

The integration of the self-scheduling component into an overall healthcare management system 
is shown in Figure 13. A completely integrated system provides patients with secure, real-time 
access to their Personal Health Record and an Enterprise Health Infonnation System (PHR and 
EHIS, respectively). Access may be provided byway of the Intemet 316 and via a Personal 
Health PortaJ (PHP) web page 1318. From the secure PHP web page 1318. patients can view 
infonnation created and maintained by their health care providers and their affiliated staff. The 
patients can also request services and infonnation from their health care providers and affiliated 
stafT directly access EHIS-related services, such as scheduling an appointment, paying a bill, 
enrolling in a class, completing frisurance and other forms, and viewing information and Intenet 
servk^es that are relevant to their particular heaUh status. 

In a prefened embodiment of the invention a patient health record data server 1302. including a 
machine readable media having a data structure containing patient created data, is coupled by an 
electronic network with a patient interface. The electronic network may be the Intemet 1316 and 
the patient interface may be a - 20 suitable Intemet access device including a browser for 
supporting a personalized web page 1318. A secure interface securely couples, in real-time, the 
patient health record server 1302 to an enterprise health record system 1304 for providing access 
by the patient to patient-related data retained within the enterprise health record system 1304. 
Thus, the patient, via the patient interface, may access the patient health record server 1302 for 
manipulating the patient-created data and for accessing the patient- related data from the 
enterprise health record system 1304. 

Referring again to Figure 13 of (he drawings, the system includes a Patient Health Record (PHR> 
data server 1302, an EHIS data server 1306, and a self scheduling server 1308. The PHR data 
server 1302 may be any suitable platform including processing, memory and data storage 
capability to perfomn the functions herein described. The PHR data server 1302 stores data 
entered by the patient within a data structure configured within the storage portion of the PHR 
data server 1302. A seepre interface or EHIS queue securely couples the PHR server 1302 and 
the EHIS data server 1 306 for communication of data and information from the PHR data server 
1302 to the EHIS data server 1306. The EHIS queue provkles a real-time secure communication 
link for tnfomnation moving from the PHR data server 1302 to the EHIS data server 1306. This 
queue is used to transfer information for secure messaging and self-service options. In response 
to information received from the PHP web page 318, the PHR data server 1302 forwards 
information to the EHIS. 

queue. Information in the EHIS queue is then processed appropriately by the EHIS data server 



While the specific configuration of the EHIS data server 1306 is not particular to the structure and 
function of the present invention, preferably, the EHIS data server 1306 is a single data repository 
structured to support both the separation and the sharing of data. As such, the EHIS data server 
1306 may receive information from existing outpatient and inpatient data management systems 
via interfaces or from various integrated applications. The EHIS data server 1306 may be 
configured to organize information into a consistent whole to provkJe a longitudinal patient record. 
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For example, the EHKS data server 1306 may be linked to manage all aspects of a patienfs 
hospital health status and care and to support effective management of patient lists, results 
inquiry management, complete clinical documentation, physician r - 21 order entry with decision 
support, nursing workflow and documentation, and discharge planning. 

The EHIS data server 1306 may further be configured to support the irrclusion of problem lists, 
order corrununications, results reporting, pharmacy management, quick documentation, clinical 
messaging and communication. Additionally, the EHIS data server 1306 may be configured to 
manage referral informatwn, up-to-date progress notes, lab results, discharge instructions, 
portions of a patienfs record, and emergency summary cards* A suitable data management 
product that may be adapted as the EHIS data server 1306 is the Epicenters Enterprise Data 
Repository and related suite of products available from Epic Systems Corporation of Madison, 
Wisconsin. 

The speci^c configuration of the scheduling server 308 is also not particular to the structure and 
function of the present Invention. However, the scheduling server may be any suitable platform 
that includes a processor, memory and data storage capability to perform the functions herein 
described. These functions may alternatively be performed by the EHIS server 1306. Thus, the 
scheduling server 1308 may be a separate component from the EHIS server 1306, or it may be 
one in the same. 

- An electronic network couples the PHR data server 1302, the EHIS server 1306. and the 
scheduling server 1308 to a patient interface. While Figure 13 depicts the scheduling server 1308 
as a separate component, as mentioned above, an alternative embodiment may include the 
scheduling server as part of the EHIS server 1306, as represented by the phantom line 1304 in 
Figure 13. The electronic network may include the Intemet 1316 or another suitable data network. 
The system servers are electronically linked to the Intemet by a web server 1312 in a highly 
secure dual firewall configuration. In this arrangement, a primary fire wall 1314 protects the web 
server 1312 and a secondary fire v/all 1310 protects the PHR data server 1302. EHLS server 
1306. and scheduling server 1308. Additionally, the PHR data server 1302, EHIS server 1306, 
and scheduling server 1308 ane also electrically interconnected. 

Patients access the system by logging into the web server 1312 via the patient interface. The 
patient Interface is preferably configured as a web page displayed within a web browser running 
on a suitable platform, and is further preferably configured as a personalized Personal Health 
Portal (PHP) web page 1318 providing the patient with patient-specific information and links to 
the features ar>d services - 22 offered by the invention. The web server 1312 may be any suitable 
web server platfonn containing routines for displaying the PHP web page 1318 and for managing 
online communk:ation between a user logged in via an associated PHP web page 1318, the PHR 
data server 1302, and the EHIS data server 1306. 

Rules-based scheduling tickets solve the many problems that the healthcare industry has 
encountered. First, the scheduling ticket could be sent to the facility via a secure web-access 
applicatkDn ensuring that the request will remain confidential. 

Furthermore, the sdf-scheduling functionality is equipped with a dynamic feedback system, which 
prevents patients from abusing their selfscheduling capabilities. For instance, if a patient 
schedules multiple appointments and does not show up for the appointments, the patient could 
be banned from scheduling any more appointments over the Intemet. Finally, because of the 
hierarchical rules that a facility could enact, the facllties, departments, and providers are able to 
determine which patients can use i scheduling tickets and which time slots they can schedule in 
at different levels, so that IS they do r>ot lose control oftheir daily schedules. 

The invention has been described in terms of several preferred embodiments, including a numl>er 
of features and functions. Not all features and functions are required for every embodiment of the 
invention, and in this manner the invention provides a flexible system by which a user may 
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access patient records, send and receive messages, retrieve Information, schedule 
appointments, renew prescriptions, pay bills and the like. The features discussed herein are 
intended to be illustrative of those features that may be implemented; however, such features 
should not be considered exhaustive of all possible features that may be implemented in a 
system configured in accordance with the preferred embodiments of the invention. 



PACE 1W29 ' RCVD AT W28/2005 9:51:39 AM [Eastern Daylight Tme} • SVR:USPTO-EFXRF-1/1 • DN1S:8729306 • CSID: 724 934*461 * DURATION (mm-ss): 12-20 



Jun 28 05 09:06a Catherine Belleci 



72493454B1 



p. 17 



Claims of GB2401 226 



CLAIMS 

1. A method of self-scheduling appointments between sen^ice recipients and service providers via 
an electronic network, the method comprising the steps of: receiving via the electronic network an 
appointment scheduling request from a service recipient; determining an authorization of the 
service recipient to submit the appointment scheduling request; identifying a pre-authorized 
scheduling ticket for the service recipient, the pre-authorised scheduling ticket including 
appointment scheduling information; providing to the service recipient an appointment proposal in 
accordance with the appointment scheduling information; and applying a set of rules to the 
appointment request to determine if the requested appointment is allowed. 

2. The method of claim 1. wherein the set of rules comprises a rule selected from the group of 
njles including: type of patient, patient insurance, referral, provider preference, past patient 
history and copay requirements. 

3. The method of claim 1 . wherein the set of mles comprises a hierarchy of rules. 

4. The method of cfaim 3 wherein the hierarchy comprises a hierarchy sefected from the group of 
hierarchical levels includir»g; system or facility, department, provider and rule. 

5. The method of claim 1, wherein the set of rules is predetermined. 

6. The method of claim 1 . wherein a rule of the set of rules is dynamic. 

7. The method of claim 1, wherein the step of determining an authorization of the service recipient 
includes authorizing a user initiated scheduling process when a scheduling ticket is not located. 

8. The method of claim 7, further comprising the step of applying a more restricted set of rules 
when an appointment is scheduled through the user initiated scheduling process. 

9. The method of claim 1 , further comprising the step of verifying the pre-authorization scheduling 
ticket. 

10. The method of cfaim 9, wherein the step of verifying the preauthorization scheduling ticket 
comprises checking at least one of the group of checks including: availability of self-scheduling 
for the service recipient, validity of the pre-authorized scheduling ticket, and availability of 
requested appointment slots. 

1 1 . The method of claim 1 , wherein the step of identifying a preauthorized scheduling ticket for 
the service recipient comprises receiving the appointment scheduling information from the service 
provider. 

12. A system to allow self-scheduling of appointments via an electronic network, the electronic 
network configured to penmit secure access thereto by a service recipient, the system comprising: 
a self-scheduling server coupled to the electronic network for secure communications therewith, 
the self-scheduling server adapted to receive appointment scheduling requests from the service 
recipient securely via the electronic network; a self-scheduling service including a processor, the 
processor being coupled to a rule base, to a scheduling database, and capable of receiving an 
appointment scheduling request; and wherein the processor is operable upon receipt of the 
appointment scheduling request to authorize the appointment scheduling request, to send 
appointment schedule information to the scheduling database for inclusion therein and to send an 
appointment acknowledgment to the service recipient securely via the electronic network. 
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13. The system of claim 12, wherein the scheduling database includes preauthorization 
scheduling infonnation associated with the service recipient. 

14. The system of claim 13, wherein the pre-authorizalion scheduling information comprises a 
pre-aulhorized scheduling ticket. 

15. The system of claim 14, wherein the pre-authorization scheduling ticket is automatically 
generated within the scheduling database. 

16. The system of claim 12, wherein the scheduling database includes information associated 
with the service recipient is manually entered through a user initiated scheduling process. 

17. The system of claim 12. wherein the system is part of an enterprise healthcare informatkjn 
management system. 

18. The system of claim 12, wherein the rule base contains a set of rules. 

19. The system of claim 18, wherein the set of rules comprises the! group of rules including: type 
of patient, patient insurance, referral, provider preference, past patient history and copay 
requirements. 

20. The system of claim 18, wherein the set of rules comprises a hierarchy of rules. 

21. The system of claim 20. wherein the hierarchy of rules comprises the group of hierarchical 
levels including: system or facility, department, I provider and rule. 

22. The system of claim 12, wherein the set of rules is predetenmined. 

23. The system of claim 12, wherein a rule of the set of rules is dynamic. 

24. A system to allow self-scheduling of appointments via an electronic network substantially as 
described and illustrated herein with reference to the accompanying drawings. 

25. A method of self-scheduling appointments between service I recipients and servfce providers 
via an electronic network substantially as described herein with reference to the accompanying 
drawings. 
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